In database management systems such as International Business Machine's (IBM) DB2 Version 7, parameters that govern an amount of inter-nodal communication resources cannot be configured dynamically. A user must estimate values of communication resource parameters with respect to workloads that will be run against a system prior to starting up an instance of a database management system. However, if the estimate is not accurate or the workloads change after the instance has been started, then communication resources can be exhausted, thus preventing the database management system from servicing certain database requests without delay.
When such an event occurs, the user has to either reissue the request after other workloads have diminished or force all applications, stop the database instance, and reconfigure the communication resource parameters with more optimal values. This is clearly a penalty on the usability and performance of the database management system, because recycling the instance and rerunning the workloads are extremely time-consuming.
In addition, since communication resources can occupy a significant amount of memory space, the user may want to release resources in exchange for memory for other purposes. However, current database engine designs require that the instance be stopped and restarted in order for the new parameter values to take effect.
Prior art solutions that may solve the dynamic configuration problem do not service requests asynchronously or undo asynchronous requests without delay. In addition, they do not permit the database server to transparently increase or decrease its communication resources in response to fluctuations in communication workload requirements.
There is therefore a need for a database management system that permits users to dynamically configure communications resources used by the system. There also exists a need for a database management system that adapts to fluctuations in workloads in a way that is transparent to the user.